home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1053 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  6.8 KB
  1. Subject: Shortcuts file and other digested material
  2. Date: Wed, 27 Jul 1994 11:41:37 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6.  
  7. SHORT-CUTS file
  8. ---------------
  9.  
  10. One global file:
  11.  
  12.     $APP_DEFS
  13. or    C:\SYSTEM\APP_DEFS.SYS
  14. or    C:\APP_DEFS.SYS
  15. or    "APP_DEFS.SYS" somewhere on $PATH
  16. or    .\APP_DEFS.SYS   // For people who don't understand wildcards :)
  17.  
  18. (Ofir suggests these last two are bad.  He's probably right)
  19.  
  20. Not just keyboard shortcuts, but general application defaults.
  21.  
  22. Application-specific and `global' setting all in the one file.
  23.  
  24. Format is "attribute_pattern: value", ie:
  25.  
  26.     *.FocusProtocol: ClickToType [or PointToType or TopWindow]
  27.     *.Open: ^O
  28.     WordProcessor*.FontSize: 12pt
  29.     *MyEdit*.Open: ^E
  30.     *MyEdit*.Font: Gemini
  31.     *MyEdit*.FontSize: 10pt
  32.  
  33. An application, say `MyEdit', would search for matches to the attributes
  34. it is interested in.  For example, it would look for:
  35.  
  36.     WordProcessor.MyEdit.FontSize
  37.  
  38. And that would match "*MyEdit*.FontSize", thus the setting would be "10pt".
  39. (matches start go `bottom-up', or `override-starting-from-top')
  40.  
  41. A set of common attributes and application types needs to be decided.
  42. >From there, we can create a APP_DEFS.SYS file that conforms to the
  43. shortcuts standard.
  44.  
  45. Multiple formats of the `value' should be supported.  For example, for
  46. key shortcuts, a standard notation like "^O" should be used by default
  47. app files, etc., but the user should be able to have a scancode if they
  48. have some key on there keyboard that is not one of the one available
  49. on all keyboards.  They'll have to provide a name for it in that case -
  50. so it can be described in a menu item.  eg. shift-< and shift->, Alt-
  51. number-pad-digit.
  52.  
  53. An application is not obliged to do what the APP_DEFS.SYS file
  54. requests, if it doesn't provide a feature.  For example, if it does not
  55. have a Find operation, that attribute is simply ignores.  Similarly, if
  56. it suppots the std GEM TopWindow FocusProtocol, then it just uses that,
  57. and ignores the setting in APP_DEFS.SYS.  
  58.  
  59. A guide for us when thinking about the APP_DEFS.SYS file may be to look
  60. at all those files cluttering C:\, and for each of them, ask `Could
  61. this have been done in the APP_DEFS.SYS file?'.  For example, the
  62. NEWDESK.INF file could have used attributes like:
  63.  
  64.     Desktop.NewDesk.Palette
  65.  
  66. Gemini would then have used:
  67.  
  68.     Desktop.Gemini.Palette
  69.  
  70. etc.
  71.  
  72. And the APP_DEFS.SYS file would have a line like:
  73.  
  74.     Desktop.*.Palette: White Black Red Green Blue ...
  75.  
  76. Or even:
  77.  
  78.     *.Palette: White Black Red Green Blue ...
  79.  
  80. So that TruePaint will use that when it searches for:
  81.  
  82.     Painter.TruePaint.Palette
  83.  
  84. Of course, I'm not suggesting we change all those programs, but it is
  85. a good guide to see if our APP_DEFS.SYS file format COULD HAVE done it,
  86. had it existed.  This indicates that future programs will find it
  87. sufficiently useful.
  88.  
  89.  
  90. The APP_DEFS.SYS file might be editing in a text editor, or by a
  91. special APP_DEFS.SYS editor (that does nice things such as allow
  92. colours and fonts and keys to be chosen through interactive dialogs).
  93.  
  94.  
  95.  
  96.  
  97. Other digested material...
  98.  
  99. Mark Baker:
  100. >Why would you want keyboard events to go to a window under the top, if you've
  101. >got to click to set the focus, why not top as well.
  102. >If you don't have to click
  103. >to set the focus (eg. under the mouse) the system is unusable as you can easily
  104. >end up typing in the wrong window.
  105.  
  106. Here's the line of reasoning:
  107.  
  108.     Q: When windows are non-overlapping, how do you know where
  109.         your keypresses are going?
  110.     A: The top window is highlighted differently.
  111.     Q: So you can tell the focus by the window decorations?
  112.     A: Yes.
  113.     Q: So if I changed the appearance of the window with the focus,
  114.         you would have exactly that.
  115.  
  116. This `change the appearance' could be changing the appearance of
  117. the cursor (ala TOSWIN and XTERM), and/or it could be changing the
  118. window colours.  On AES >=4.1 and under WINX, this can be done
  119. regardless of whether the window is on top (just wind_get the default
  120. Active colours, and wind_set them on your window-under-focus).  I hope
  121. to be able to provide a demonstration of this in the next week.
  122.  
  123. Kevin O'Donovan:
  124. >cut and paste from text fields
  125.  
  126. This I really miss on my machine at home, after using X11 all day at work.
  127.  
  128.  
  129. Michel Forget wrote:
  130. >Hello Warwick,
  131. >>you can still use raster
  132. >>copies on partially obscured windows.
  133. >
  134. >Could someone who understands how to do this post on the subject?
  135.  
  136. Think of how you normally scroll a window upwards 1 pixel:
  137.  
  138.     1. Raster copy upwards all but the top line of pixels.
  139.     2. Redraw the bottom line of pixels.
  140.  
  141. All you do for partially obscured windows is:
  142.  
  143.     For each rectangle in the window's clip list (wind_get(first/next...)):
  144.         1. Raster copy upwards all but the top line of pixels.
  145.         2. Redraw the bottom line of pixels.
  146.  
  147. ie. exactly the same, but for each clip rectangle.
  148.  
  149. (2) is, I guess, slightly tricky in that you have to work out what
  150. to redraw, and that's slightly more complicated for the second version.
  151.  
  152. But it works like a charm.
  153.  
  154. (BTW, I wasn't criticisin MB - it *is* the fastest GEM text file viewer
  155. available - I was just using it as an example of background windows not
  156. being optimized)
  157.  
  158.  
  159.  
  160. Someone:
  161. >Whomever:
  162. >> Here's an idea for operating back-ground windows...  put an event 
  163. >> rectangle around your window and watch for the mouse to move outside of 
  164. >> your window.
  165. >
  166. >This is not necessary, and it is very time-wasting.  Considering, that
  167. >when you move your mouse, you are checking the rectangles under the mouse
  168. >for which object your mouse moves under for the top window.
  169.  
  170. Actually, `Whomever' was quite close to the mark.  Using large rectangles is
  171. the best approach.  (But the remainder of Whomever's solution was incorrect,
  172. as Someone pointed out).
  173.  
  174. In general, there are 3 solutions to hot-tracking, in order of efficiency:
  175.  
  176.     1. Tracking mouse movement by large areas, only returning to the
  177.         application when it needs to re-decide the rectangle
  178.         to look at.
  179.  
  180.     2. Tracking a single pixel rectangle, thus returning to the
  181.         application whenever the mouse moves.
  182.  
  183.     3. Using a zero-interval timer, thus returning immediately to
  184.         the application.  This is busy-waiting.
  185.  
  186. The first is a little more difficult to implement.  The second and third
  187. are both trivial.  Hence the third technique can be disregarded, unless
  188. you are already busy-waiting for other reasons (eg. continuous animation).
  189.  
  190. >Simply do this:  A button "press" activates a dialog inside a background
  191. >window.  A button "click" tops the window.  Press meaning hold down the
  192. >mouse button.  Click meaning tapping the mouse button.
  193.  
  194. On a fast machine, `click' should be indistinguishable from `press', unless
  195. a real-time delay is used.  Note that GEM already incorporates such a delay
  196. for calculation of double-clicking, so if you are waiting on double-clicks,
  197. this may be usable - I'd have to look at an actual implementation to know.
  198. Certainly anything that depends on CPU speed is unacceptable.
  199.  
  200.  
  201. --
  202. Warwick
  203.